終於到了「如何提升系統品質」系列文的最後一篇了，在總結之前，要談的是code review。

每間公司、每個團隊有自己的文化，code review的方式、標準可能都不一樣，所以這邊只是概略的提個經驗分享，但要記住的是，如果前面一整個系列大家都有follow到，到code review時，就是畫龍點睛的效果囉。

最後，我會將這一系列文章分出不同的類別，供大家參考。

[如何提升系統品質]系列文章連結
前言
整個系列提到了許多輔助我們維護品質、品質檢測的工具，有了這麼完善的基礎建設、工具、品質好的設計與開發方式，就可以保證品質到達完美了嗎？

很遺憾的，不是。

這些輔助工具、檢測數據，都是一些輔助我們客觀觀察系統品質的重要基石。但設計系統並沒有這麼簡單，還是有很多東西是工具無法幫忙檢測出來的。

Code Review針對的議題
如果已經有前面一整個系列工具的輔助，數據的輔助，在整個開發的過程持續的維持著這樣的品質，code review的速度就可以很快，因為只需要針對工具無法cover的部分review。

下面提出幾個議題，可能工具也可以輔助，但因為很重要，所以還是要在提出來一次。
1.設計的功能是否符合需求。

2.整體架構設計是否未來擴展的需求。

3.安全性是否安然無虞。(至少要通過FxCop等免費工具檢測)

4.系統目錄結構編排方式是否合理。

5.針對系統的領域，是否有特殊需求需要考量。（例如為了符合架構所衍生出的特別設計，Cache, Message Queue, load balance等等..）

6.交易控管的合理性。

7.是否需衍生出監控機制、資料檢查機制、看門狗的設計。

Code Review的方式(個人經驗，僅供參考)
1.請一定要抽時間出來做code review (一週兩次，一次半小時)。

2.每次盡量不超過半個小時。

3.目的是儘速瞭解功能需求、分析與設計方式。

4.讓reviewer來主導code review流程，而非寫code的人。

5.Code review前準備好文件、可以建置成功（最好可以執行測試或demo），且通過前面整個系列品質檢測的程式碼（因程式碼可能還沒完整完成，品質指標門檻可以下修）。

6.針對CI產出的報表，需要重構的地方進行檢討與建議。

7.過程中不修改code，最多加上todo，再透過IDE的工作清單快速找到此issue。

8.Code review完要做會議記錄。

品質文章分類
1.程式碼規範：
需符合Code Convention，請參考：[如何提升系統品質-Day16]Code Convention

工具：StyleCop, FxCop, VS2010的靜態程式碼分析...

2.命名原則與建立統一命名：
原則，請參考：[如何提升系統品質-Day1]命名的重要性
建立統一命名請參考：[如何提升系統品質-Day12]命名-Glossary的建立

工具：StyleCop, FxCop, Wiki, Excel, GoogleDoc...

StyleCop的介紹，請參考：[如何提升系統品質-Day17]品質量測工具-StyleCop

FxCop的介紹，請參考：[如何提升系統品質-Day18]品質量測工具-FxCop

3.分層，降低耦合，提高可維護性
請參考：
[如何提升系統品質-Day2]重構– UI, Business logic, Data access概念分開

工具：VS2010的Dependency Graph, Layer Diagram，以及NDependency...

4.避免重複的程式碼
請參考：
[如何提升系統品質-Day3]重構– DRY & Top-Down思考方式(1)
[如何提升系統品質-Day4]重構– DRY & Top-Down思考方式(2)

工具：Simian...

5.抽象地設計程式
請參考：
[如何提升系統品質-Day8]重構-抽象來看程式是否符合DRY原則
[如何提升系統品質-Day3]重構– DRY & Top-Down思考方式(1)
[如何提升系統品質-Day4]重構– DRY & Top-Down思考方式(2)

工具：UML, VS2010反向工程產生Sequence Diagram

6.降低複雜度與耦合性
請參考：
[如何提升系統品質-Day9]重構-簡化判斷式
[如何提升系統品質-Day10]重構-合併重複的條件片段
[如何提升系統品質-Day11]重構-使用介面+迴圈取代不穩定的判斷式

好的設計原則，請參考：
[如何提升系統品質-Day6]重構-簡單使用interface之『你也會IoC』
[如何提升系統品質-Day27]設計 - Aspect-oriented programming(AOP)

工具：
SourceMonitor，請參考：[如何提升系統品質-Day13]品質量測工具- SourceMonitor簡介
VS2010程式碼度量，請參考：[如何提升系統品質-Day14]品質量測工具- Visual Studio 2010 程式碼度量

7.透過測試來提升品質
請參考：
[如何提升系統品質-Day7]測試-單元測試, Just Do It!!
[如何提升系統品質-Day22]測試 - 單元測試的意義
[如何提升系統品質-Day23]測試 - 單元測試工具的選擇(for .NET)
[如何提升系統品質-Day24]測試 - Code Coverage
[如何提升系統品質-Day25]測試 - 自動化測試經驗分享
[如何提升系統品質-Day26]測試 - 問題單該提供的資訊
[如何提升系統品質-Day19]測試 - Web測試工具簡介

工具：
VS2010, NUnit, NCover, Rhino Mocks, Selenium...

8.安全性
請參考：
[如何提升系統品質-Day20]Security - SQL injection
[如何提升系統品質-Day21]Security - Cross-Site Scripting(XSS)

工具：
FxCop, VS2010程式碼分析, CAT.NET, Fortify...

9.效能
請參考：
[如何提升系統品質-Day28]Performance

工具：VS2010, YSlow, PageSpeed, SQL profiler...

10.基礎建設
請參考：
[如何提升系統品質-Day15]基礎建設-版本控管的重要概念
[如何提升系統品質-Day29]基礎建設-持續整合(CI)

以上！！（感覺好像在打絕世武功秘笈.....的目錄）

結論
回到這一整個系列的主題：系統不是會動就好！！

這一整個系列，洋洋灑灑三十篇介紹，每一項都符合了『即使不做，程式還是可以動』的原則。對我來說，程式可以完成功能，完成度大概只有20％。您呢？捫心自問一下，程式除了會動以外，您為您的系統品質做到了多少呢？

上述10點，加上這一篇的Code Review要點，希望可以幫助大家，讓大家的系統都不只能動，還擁有人人稱羨的好品質。為了品質的付出，最後總是會有人受益的，通常受益者都是自己。

後記
這一系列文章，受到了很大的阻力跟鼓勵。

看著其他一些參賽者的系列文，我不敢說我一定比他們好，但比認真程度，我真的覺得我認真太多了，每天像傻子一樣閉關survey跟寫文（鐵人賽還沒開始前，我就已經開始survey系列文相關主題了）...很多朋友說我很傻，但我真的想要為台灣的軟體業盡一份心力。

為什麼我們要繼續活在無間地獄？我們痛恨著前人留下給我們的包袱，我們痛恨著團隊開發時阻力比助力多，我們痛恨著一再重複、乏味、繁瑣的動作！這麼多的痛恨，這麼多的苦難折磨，除了帶給我們抱怨，是不是可以從我們這邊築起一道防火牆，讓未來的火不要在燒到後人呢？

大家在怨嘆台灣的資訊業、軟體業能力不足、品質不足、人員地位低落、老闆無腦的同時，是不是也可以想一下，如何為這樣的環境創造出不同的活水，盡一份心力，就像環保一樣，改變可以從自己做起。

最後，感謝這一年一度的鐵人賽，感謝主辦單位能有這麼有意義的活動與傳統，希望我這一系列的努力、付出，可以替這個活動增添一些色彩，希望少一點謾罵、批評，多一點肯定。也希望最後評審可以憑著專業、良心，做出最公正、公平的評分。

第四屆鐵人賽，是我連續參加的第三年了，對我的意義很特別。（如果第一屆早一點知道，或許今年就可以連四了。）也希望鼓勵自己和其他人，繼續保持著熱忱、熱血，衝啦！

PS：雖然已經30篇了，我會再整理一篇是這30篇系列文裡面，我認為很不錯的Reference供大家參考，希望讓大家滿載而歸！